Machine Type Communication (MTC) devices (sometimes referred to as Machine-to-Machine or M2M devices) are increasingly being used for a variety of applications. Their numbers are expected to grow at a high rate. MTC devices are typically automated data reporting systems such as utility meters or status reporting devices. MTC devices can be standalone devices serving one application: for example smart metering devices or can be regular cellular network User Equipments (UE) with MTC applications.
The MTC applications are likely to have significantly different usage or operational characteristics from other types of User Equipment (UE) applications. Such devices may be programmed to send data at a specific time, for example late at night. Also, other types of MTC devices may be triggered by specific events, such as a burglar alarm. Many of these may activated by the same event (for example, a power cut or earthquake). In any event, the volume of data transmitted and received by such devices is often low.
It has conventionally been understood that nearly all MTC devices (or at least 95%) will operate on their home cellular radio network, referred to as the Home Public Land Mobile Network (HPLMN). This is identified by the PLMN-ID of their International Mobile Subscriber Identity (IMSI). It has therefore been thought that network operators would be able to manage the large number of MTC devices by dimensioning their networks accordingly. Hence, MTC devices are generally expected to act and to be treated no differently from any other type of UE. In some critical network error conditions, where the HPLMN is unable to serve some particular device, then the network enables access barring and makes the UE to try after some time, by providing back-off timer values. From a UE perspective, since the HPLMN is available, the UEs will keep on trying to attach with the HPLMN. This access barring mechanism will make the UE to keep trying access attempts in the HPLMN and this will drain the device battery power faster. Also if the network enabled the access barring due to overload condition, this frequent attempts from the barred UEs will further make the network overload and consumes the network resources unnecessarily, as the network is not sure when it can recover from such unable to serve condition. It has to be understood that with the existing Access Class Barring/Extended Access Barring (ACB/EAB) mechanism wireless devices like the MTC devices can get into no service scenarios and this amounts to non-service availability which has regulatory and legal implications as users are promised service by an operator. Operators want to avoid this situation and are therefore looking at an appropriate technical solution.
An appropriate solution mechanism was so far not possible as operators did not want to let another operator to serve their subscribers within a particular service area and technically the PLMN selection hierarchy was so designed to avoid any attachment of a UE to a not intended operator network. Also, as the PLMN selection mechanism was preprogrammed or prelisted into a Subscriber Identity Module (SIM), any drastic PLMN selection changes was not possible. In the current mechanisms, networks do not have the option to make the UEs to try to attach other network immediately or try to attach the same PLMN with different radio access technology, if the highest priority PLMN (like HPLMN) is available. Going forward it is also possible that network operators will implement dynamic spectrum sharing or dynamic inter operator policies and when such policies are implemented and network operator may use such additional spectrum or additional rights to offload to other operators when there exists no mechanism to offload users to such additional spectrum or make use of such additional rights for possibly offloading to other operator networks dynamically based on the said operator network conditions and policies.
The introduction of a large number of MTC devices leads to overload conditions in Long Term Evolution (LTE) networks. Such overload scenarios could lead to severe network failure and service disruptions. Recently 3GPP has started discussing over load issues in LTE network due to the introduction of a large number of MTC devices. Also typically the network operators face two types of overload namely, Core network overload and Access network overload. The Core network overload can be independent of the access network overload. Commonly such overload condition in LTE networks leads to service disruption conditions for UEs or UEs tend to view this as severe network failure.
In an existing system, there exists an EAB mechanism to handle the issue of core network and access network overload, but this mechanism does not distinguish Access network overload and Core network overload. The EAB is similar to the ACB for the UEs. However, with the EAB or ACB mechanism if the core network is overloaded, the operator will invoke the EAB or ACB mechanism even though the radio access network (RAN) is not overloaded and the UEs will go in to wait time or back-off time. There is no way of using the services of another core network when the EAB or ACB is invoked by the network or the core network is unable to serve, even though an alternative core network could be a shared network or a roaming partner which can serve the UE.
Further, the mechanism of keeping the wireless devices into wait time will not serve all classes of devices. Some of the devices might require timely access guarantees and the EAB mechanism (extended wait time) might not guarantee access within the required time. There might, then be service disruption for MTC devices. In such cases enhancements or alternatives to the EAB mechanism is required for providing reliable access. Some wireless devices like the Low cost MTC devices might also be low on memory and might not have the capability to hold onto too much data when a network pushes the wireless device into an EAB/ACB mode. In such cases the devices might be forced to rewrite data on the old available data leading to loss of data.
Presently, with the extended access barring (EAB) mechanism or access class barring (ACB), the MTC devices or UEs are indicated about the non availability of service through indications in system information or through reject cause value in the reject messages. Such mechanism allows for time based barring of the MTC devices or UEs which leads to service disruption for these devices or in other words these devices perceive the network to be in a severe error condition leading to service disruption. This can cause unwanted delays for time critical MTC devices. Further, in the present scenario, there is no classical definition of what type applications are supported by the MTC devices. The applications can be latency tolerant application like smart meters or time critical applications like medical applications. Also currently the PLMN hierarchy provides a UE to go for next available PLMN in the hierarchy if a service from a PLMN is unavailable, instead the invocation of the EAB/ACB/reject mechanism will keep the UE in back-off mode and UE will keep re-attempting to access the network with the back-off timer value provided by the network, being increased after each attempt. This leads to long delays before a UE can come out of an EAB/ACB mechanism and access a network to transmit critical data. This current UE and network behavior mentioned in the specifications leads to unacceptable delays and leads to the UE perceiving severe network failure under the specified conditions. This is an unacceptable situation. Due to the above mentioned reasons, there is a need in the art to reestablish mechanisms to alter the UE behavior in order to support continued service for MTC or normal wireless devices when the network is unable to serve UEs under severe error conditions.
In the light of above discussion, it is desirable to have a method and system for providing continued services to a UE under severe network failure conditions like overload conditions. It is further desirable to have a method for indicating to a UE to invoke an alternate network access behavior instead of the existing UE behavior when an EAB/ACB is invoked by the network or under a severe network failure condition in the network. It has to be understood that a lack of such a service continuity solution for wireless devices is a serious regulatory issue and that this can affect the service experience of millions of devices which are getting added into the networks. Existing ACB/EAB mechanism becomes restrictive in their use as it was never conceived or designed with service continuity. This has been a failure on the part of the design community to address the issue of service continuity when handling the critical network error issues.
Further, an “unable to serve condition” in a network might not always indicate an error; other possible causes can be “better service available in another network” or “new spectrum becomes available to the operator” or “new inter operator policies becomes enabled” through which the operator now has the rights to use part of an other operators network resources and the current operator would then like to initiate an inter-operator offload to balance the network.